Summary & Motivation

Improve render and interaction performance on global search for users with very large workspaces.

A key part of the problem here is that writing/reading with the Apollo cache becomes prohibitively slow at scale. Therefore:

• Use cache-first policy on search queries. Currently, we always hit the backend when opening search, which can be expensive both in terms of performing the query and updating the cache. Instead, we can leverage the workspace and asset catalog queries to read data from the Apollo cache, if available.
• Only query or read the cache once per search query. If we already have WebWorkers set up for search, don't repeat the query at all, even to do a cache lookup -- the data is already available on the workers. Just go straight to the existing workers, thus making search instantly available.
• Skip the Apollo cache entirely for the run timeline query. When the user has a huge number of runs, the Apollo cache read/write can be very slow, blocking the main thread and affecting everything else on the page. Since this data needs to be fresh in all cases anyway, just skip the cache.

How I Tested These Changes

Viewing the app as a user with tens of thousands of objects, open search after the workspace and asset catalog have loaded. Verify that new queries are not performed, and that the data is available to be searched as soon as the cache has populated the values. Close search, reopen it. Verify that search is available right away, without having to wait for the cache to populate the values.